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@ Method and apparatus for detecting and executing cross-domain calls in a computer system. 



(57) In a computer system, an improved technique 
detects and executes cross-domain calls in an 
application program. The invention determines 
whether a branch target address falls within a 
reference address range within a first domain. If 
it does, the invention executes the call by deter- 
mining a called address in a second domain 
con^sponding to the target address in the first 
domain, e.g., by mathematically manipulating 
the target address. The invention then accesses 
the called address and executes the code 
stored therein. The invention may be used in 
detecting and executing cross-domain calls 
from an application program executing by inter- 
pretation in an emulated computer system hav- 
ing a first architecture (e.g., "CISC"), where the 
calls seek execution of specified system ser- 
vices functions executable directly in a com- 
puter system having a second, different 
architecture (e.g., "RISC"). The invention also 
may be used in a computer system having 
multiple processors of heterogeneous architec- 
tures. 
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FIELD OF THE INVENTION 

This inv ntion relates generally to computer sys- 
tems, and more particularly to techniques for detect- 
ing and executing cross-domain calls. The invention 5 
finds particular utility for operating an emulation sys- 
tem to execute programs on a computer system hav- 
ing an architecture other than that for which the pro- 
grams were written. The invention also finds particu- 
lar utility In a multi-processor computer system In io 
which the processors are of different architectures. 

BACKGROUND OF THE INVENTION 

A computer architecture can be defined as the at- is 
tributes of a computer established at the hardware 
and machine language level, in contradistinction to 
those available for manipulation at a higher software 
level, e.g., by application programs. Generally speak- 
ing, architectural attributes include, e.g., an instruc- 20 
tion set, instruction format, operation codes, address- 
ing modes, register locations, and memory locations, 
including those that define machine state. 

CISC and RISC are two types of architectures 
prevalent today. "CISC" stands for complex instruc- 25 
tion set computing, e.g., as embodied in IBM™-com- 
patible personal computers incorporating 80X86 
processors from Intel Corporation. CISC machines 
are characterized by variable-length instruction for- 
mats, a large number of addressing modes, small-to- 30 
medium-sized register files, register-to-memory (or 
memory-to-memory) instructions, and microcoded 
execution of instructions. "RISC" stands for reduced 
instruction set computing, e.g., as embodied in com- 
puters incorporating ALPHA AXP™ processors from 35 
Digital Equipment Corporation. RISC architectures 
are characterized generally by simple, fixed-length 
instruction formats, a small number of addressing 
modes, large register files, a load-store instruction 
set model, and direct hardware execution of instruc- 40 
tions. 

It is often desirable to execute programs on com- 
puters conforming to one type of architecture, though 
the programs were designed for execution on ma- 
chines conforming to another, different type of archi- 45 
tecture. For example, programs designed for execu- 
tion on CISC computers may need to run on RISC na- 
chines. In order to do so, some form of "software" 
bridge must be furnished between the two architec- 
tures. 50 

A complication in providing that software bridge 
arises from the need in many CISC (e.g., 80X86) pro- 
grams for system services functions ("SSF") to sup- 
port program execution. SSF typically include (I) ba- 
sic input/output system ("BIOS") functions for control- 55 
ling video, disk access, system clock, etc., and (ii) op- 
erating system functions for providing program load- 
ing and unloading, network control operations, file 



services, etc. 

During execution, the application programs fre- 
quently "call" SSF's, i.e., branch to SSF routines nor- 
mally provided, e.g., by the CISC system software. 
Each branch (i.e., change from sequential program 
flow indicative of a call) will specify, directly or indir- 
ectly, a target address to which control is to pass. 

For example, the application programs can in- 
clude branches in the form of interrupts. The inter- 
rupts specify interrupt numbers for use as indexes 
into an interrupt vector table ("IVT") identifying target 
addresses of SSF routines. Control is passed to the 
SSF routine designated by the interrupt number. Ap- 
plicable standards for lBM™-compatible personal 
computers specify SSF routines accessible via par- 
ticular interrupt numbers. Other form of branches in- 
clude branch instructions and jump instructions, 
which typically directly specify target addresses. 

The software bridge for enabling cross- 
architecture execution of application programs can 
be furnished in a number of different ways. First, the 
application program can be translated into a new pro- 
gram that executes, e.g., on the RISC computer. This 
can be a time-consuming, costly procedure, which 
may require the authorization of an owner of any in- 
tellectual property rights in the program. Second, in 
the alternative, a RISC computer can be used to emu- 
late, preferably transparently, the CISC architecture, 
thereby enabling it to execute CISC application pro- 
grams. 

During emulation, the RISC computer creates the 
illusion of a CISC machine for program execution pur- 
poses. Creating that illusion requires emulation of the 
operating environment of the CISC machine, includ- 
ing its processor, system software, peripheral hard- 
ware, and memory; in short, emulation of all compo- 
nents and resources that the application program 
would "expect" to be available to It during execution. 

After creating that illusion, the RISC computer 
executes the application program using a process 
called "interpretation." In other words, the RISC com- 
puter decodes and parses the application program to 
obtain state information that would result from exe- 
cuting the program on a CISC machine, and then 
identifies and executes corresponding code in the 
RISC system that performs equivalent operations. 

While conventional emulation systems are gen- 
erally suited to their intended purposes, they encoun- 
ter certain limitations and drawbacks. For example, 
conventional emulation systems can have difficulties 
in efficiently executing SSF called by application pro- 
grams. 

Called SSF routines can be provided during pro- 
gram execution either in the CISC instruction set for 
execution via translation or interpretation, or in the in- 
struction set of the RISC architecture for direct exe^ 
cution. Direct execution of the SSF routines in the 
RISC computer can realize performance and other 
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gains over the other techniques because it is faster 
than interpretation, and more economic than transla- 
tion. 

Execution of the application programs via inter- 
pretation with direct execution of called SSF routines 
requires a mechanism to detect when the application 
programs transfer control for execution of the SSF 
routines. The detection mechanism must be able to 
distinguish calls that seek to pass control to the SSF 
routines (i.e., between the CISC emulation and the 
native RISC machine) from those that merely seek to 
pass control to other routines in the same application 
program. The former are referred to as cross-domain 
calls, with the CISC emulation representing one do- 
main and the RISC machine the other. 

Detecting cross-domain calls is significant in 
contexts other than emulation systems. For example, 
many computer systems have multiple processors, 
e.g., within a single enclosure or disposed remotely 
and connected by communication links. Increasingly, 
the processors within the system are of different ar- 
chitectures, thus the system can be said to embody 
two or more (i.e., multiple) domains. To take advan- 
tage of such a heterogeneous environment, the proc- 
essors sometimes make cross-domain calls for exe- 
cution of routines by other processors in the system. 
It would be desirable to provide a mechanism for ef- 
ficient and reliable detection and execution of such 
cross-domain calls. 

SUMMARY OF THE INVENTION 

The invention resides in an improved technique 
for detecting calls from a first domain to a second do- 
main by providing a reference address range within 
the first domain indicative of a cross-domain call. In 
its broad form, the invention resides in a computer- 
implemented method for detecting and executing a 
call from a first program, for execution of a second 
program, as in claim 1, and corresponding apparatus 
as In claim 8. If the target address of any branch falls 
within the reference address range, the invention exe- 
cutes the call as a cross-domain call. 

In order to execute the cross-domain call, the in- 
vention determines a called address in the second do- 
main corresponding to the target address in the first 
domain by mathematically manipulating the target ad- 
dress. The invention then accesses the called ad- 
dress and executes the code stored therein in the sec- 
ond domain. The Invention can then return the results 
of executing that code via a return cross-domain call 
to the program executing in the first domain that in- 
voked the call. 

The mathematical manipulation of the target ad- 
dress can take any of a variety of different forms. For 
example, the arithmetic difference between the tar- 
get address and one of the boundaries of the prede- 
termined range can be calculated and used as an off- 



set into a second predetermined address range in the 
second domain to yield the called address. 

Alternatively, an arithmetic operation can be per- 
formed on the target address, such as the addition, 
5 substraction, or multiplication of the target address 
(which is treated as an integerfor these purposes) by 
a constant. Another embodiment uses a transforma- 
tion polynomial on the target address to yield the 
called address. 
10 An illustrative embodiment of the invention uses 

a "phantom" table, called a "cross-domain reference 
space" or "CRS" to establish the reference address 
range. The CRS can have a plurality of independently 
addressable memory locations, for example, the 
IS smallest permitted by the architecture (e.g., a single 
byte), each corresponding to a callable address in the 
second domain. The contents of the CRS are prefer- 
ably not used in the invention, hence, the designation 
of that table as "phantom." 
20 To determine whether a particular call is a cross- 

domain call in this embodiment, the branch target ad- 
dress of the call is used as a pointer to designate a 
corresponding address of an entry in the CRS, either 
directly or via an interrupt vector table. If a corre- 
25 spending entry in the address space of the CRS ex- 
ists for the target address, the call is treated as a 
cross-domain call. 

Then, an offeet is calculated, which equals the 
difference between the designated CRS address 
30 and, e.g., the lowest address of the CRS. This offset 
is then used in accessing a second-domain address 
table. .... 

The second-domain address table preferably has 
the same number of entries as the CRS, each of 
35 which containing a representation of an address with- 
in the second domain's address space of code to be 
executed. The calculated offset in the CRS can be 
used to access the second-domain address table, 
e.g., by adding it to the lowest address within that ta- 
40 bie, and then using the resulting sum as an address 
of an entry therein to be accessed. 

In an illustrative implementation of this embodi- 
ment, the second-domain address table is a function 
address table ("FAT"), and the accessed entry con- 
45 tains the address of a called system services routine 
stored in a system services function space ("SSFS") 
By practicing this embodiment, the program that 
invoked the call can be executed (e.g., executed in an 
emulated environment by interpretation) on a first 
50 computer system having an architecture different 
from that for which the program was written. More- 
over, the system services functions required by that 
program can be directly executed, e.g., on the com- 
puter system hosting the emulation, even though it 
55 has a different architecture. 

This embodiment of the invention can achieve a 
number of additional advantages. For example, 
cross-domain detection using the CRS consumes. 
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e.g., only one byte of address space in the emulated 
CISC domain per each systems function, and, even 
then, the CRS need not store data or code in that ad- 
dress space for purposes of the Invention. Where the 
emulation is of an 80X86 machine with Its notoriously 
limited address space for conventional memory, this 
feature of the Invention can be of particular benefit. 
Another significant advantage is that this embodi- 
ment requires neither modification of the application 
programs being executed, nor advanced interpreta- 
tion of the program. Yet another advantage is that this 
embodiment provides the ability to readily support 
commodity personal computer hardware, e.g., graph- 
ics boards and other devices connectable via an ex- 
pansion bus to a computer system of a non-conform- 
ing architecture. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more detailed understanding of the invention 
may be had from the following description of a prefer- 
red embodiment, given by way of example, and to be 
understood in conjunction with the accompanying 
drawings, wherein: 

Fig. 1 is a blocl< diagram of a computer system In- 
cluding an emulator for executing application pro- 
grams in accordance with an embodiment of the 
invention; 

Fig. 2 Is an illustrative representation of the struc- 
ture and mapping of the address space of the 
memory of Fig. 1 , showing those aspects pertain- 
ing to detection and execution cross-domain 
calls; 

Fig. 3 is a blocl< diagram of a method of Initializing 
the computer system of Fig. 1 for cross-domain 
call detection and execution by setting-up the ta- 
bles of Fig. 2; 

Fig. 4 is a block diagram of a run-time method for 
detecting and executing cross-domain calls in the 
computer system of Fig. 1 ; and 
Fig. 5 is a more detailed representation of the ad- 
dress space of Fig. 2 in accordance with an illus- 
trative implementation of the invention. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENT 

Fig. 1 shows a host computer system 10 in accor- 
dance with the invention. The computer system 10 
embodies a first architecture, and has a conventional 
CPU 12, system software 14 (Including, e.g., an op- 
erating system) for controlling operation of the sys- 
tem 10, and a memory 16. 

The host computer system 10 also includes con- 
ventional user interfaces 24 and peripheral hardware 
28 coupled to the CPU 12. The user Interfaces 24 in- 
clude, e.g., a display or monitor 24Aand a keyboard 
24B for providing displayed outputs and for enabling 



a user to enter commands and data, respectively. The 
peripheral hardware 26 includes, e.g., conventional 
disk controllers, keyboard controllers and Input/out- 
put ("I/O") ports (not separately shown). 
5 The host computer 10 further includes an emula- 

tor 30 implemented preferably in software executable 
by the CPU 12 for emulating, a computer system 32 
embodying a second, different architecture. Conven- 
tional emulation systems are well known to those of 
10 ordinary skill in the art. 

For convenience in distinguishing between the 
computer systems 10, 32 herein, the host computer 
system 10 and its components and code written for 
the first architecture shall be referred to as "native." 
15 Analogously, the emulated system 32 and its compo- 
nents and code written for the second architecture 
shall be referred to as "foreign." 

The second system 32 essentially is an "illusion" 
created by the emulator 30, of a foreign CPU 34 for 
20 executing foreign code, e.g., at least one, foreign ap- 
plication program 35. The emulator 30 also generates 
an emulation of foreign system software 36 for con- 
trolling operation of the computer system 32, and an 
emulation of foreign peripheral hardware 38. The ap- 
25 plication program 35 comprises a sequence of In- 
structions (i.e., lines of code) conforming to an in- 
struction set mandated by the second architecture, 
which are adapted for execution on the foreign CPU 
34. The application program 35 includes branches 
30 (i.e., changes from sequential program flow) for pass- 
ing control to one or more SSF routines, as described 
below. 

In an iilustrative.application of the invention, the 
host computer system 10 can be a RISC machine, 

35 such as, e.g., the ALPHA-AXP-based computer men- 
tioned above, and the foreign computer system 32 
can be a CISC machine, such as, e.g., the 80X86-ba- 
sed machine also mentioned above (often referred to 
as an "IBM compatible computer", where IBM is a 

40 trademark). 

Fig. 2 depicts memory 16 as including a native 
domain address space 52 and a foreign domain ad- 
dress space 54. The native domain address space 52 
has privileged access from computersystem 1 0 of the 

45 native domain. The foreign domain memory space 54 
has privileged access from the computer system 32 
provided by emulator 30. The native domain address 
space 52 Includes a system services function space 
("SSFS") 56, and a function address table ("FAT") 58. 

50 The foreign domain address space 54 includes a 
cross-domain reference space or table ("CRS") 62, 
and an interrupt vector table ("IVT") 64. 

First, the native domain address space 52 will be 
discussed in greater detail. The SSFS 56 stores the 

55 SSF's as entries designated SSF_0, SSF_1 and 

SSF_IM; each entry is uniquely identified within the 
native domain address space 52 by a corresponding 
address SSF_ADfi_0, SSF_ADn_1 and 
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SSF_ADm_K, where "K" is a positive integer. 

The FAT 58 has a number of ntries designated 
0 through M, where "IVl" is a positive integer, each 
storing a representation of one of the SSFS address- 
es SSF_AD^lO, SSF_ADn_1, ... , orSSF_ADN_Kof a 5 

. corresponding entry SSF_0, SSF_0 or SSF_K in 

the SSFS 56. Preferably, "M" is less than or equal to 
"K", the number of system services functions repre- 
sented by entries in the SSFS 56. ("M" can be less 
than "K" where a sub-set of the SSF are to be made io 
available for a particular program's execution;) The 
FAT 58 occupies a range of addresses FAT_AD|>l_0 to 
FAT_AD|>L.M within the native domain address space 
52. 

With respect now to the foreign domain address is 
space 54, the CRS 62 has a number of entries, des- 
ignated entry 0 through entry "M," located at respec- 
tive addresses CRS_ADf_0 through CRS_ADf_M. 
Preferably, each entry 0-M occupies the smallest in- 
dependently accessible block of locations in the for- 20 
eign domain 54, e.g., a single byte. 

Moreover, the number of entries 0 - M in the CRS 
62 is equal to the number of entries 0 - M in the FAT 
58, i.e., "M". In otherwords, the addressable locations 
in the FAT 58 and CRS 62 are allocated in matched 25 
pairs, each pair corresponding to one of the SSF's 
available for implementation in the system 10. 

The CRS 62 is used as a reference table only; 
therefore, no code is required by the invention to be 
stored in the entries 0 - M of that table. Essentially, 30 
the CRS 62 is the foreign-domain counterpart of the 
native-domain's FAT 58, and is used only in denying 
a pointer into the FAT 58. Indeed, the portion of the 
emulated domain address space 54 reserved for the 
CRS 62 can be used independently of the invention 35 
for storing data or code required for other applica- 
tions. 

The IVT 64 contains a number of entries desig- 
nated CRS_AD_0, CRS_AD_1, ... , CRS_AD_M, 
each corresponding to a respective interrupt number 40 
INT_0 through INT_M. Each IVT entry CRS_AD_0, 

CRS_AD_1 CRS_AD_M, is accessible using the 

corresponding interrupt number as a pointer into the 

IVT 64. Each entry CRS_AD_0, CRS_AD_1 

CRS_AD_M represents an address of a correspond- 45 
ing entry in the CRS 62. 

The IVT 64 can also have entry locations contain- 
ing branch target addresses MEM_AD_0, 

iV1EIV1_AD_2 I\)1EM_AD_P that do not fall within 

the range of addresses CRS_AD_0 to CRS_AD_M so 
within the CRS 62, and thus do not require cross- 
domain calls. For example, the addresses 

MEM_AD_0. I\(1EM_AD_2, MEM_AD_P may be 

target addresses for calls for routines within the ap)- 
plication progi-am 35 (Fig. 1) itself. 55 



A. Initialization and Set-Up of Tables 

Fig. 3 shows a method 1 00 of intializing the com- 
puter system 10 (Fig. 1) to set-up the tables 56, 58, 
62, 64 (Fig. 2). 

Block 102 generates the CRS 62 by performing 
a number of sub-steps. Sub-block 104 locates and si- 
zes the CRS 62 by reserving a range of addresses 
CRS_ADf_0 through CRS_ADf_M (i.e., a section) of 
the foreign domain address space 54 for the CRS and 
determining the number of bytes required in the ad- 
dress range, e.g., a single byte per address. Sub- 
block 1 06 allocates locations in the CRS 62 to FAT en- 
tries. For example, each single-byte location in the 
CRS 62 conresponds to a FAT entry at which is stored 
an address (e.g., a 32-bit address) in the native ad- 
dress space conforming to the architecture of the 
computer system 1 0. The stored address is of an en- 
try point (e.g., first line of code or first instruction) of 
an SSF routine. 

The foregoing arrangement achieves a number of 
advantages. For example, the CRS 62 can be config- 
ured to be of minimal size, e.g., having only a single 
byte per SSF instead of bytes sufficient to hold an en- 
tire native domain address, e.g., 32 bits, for each 
SSR 

Block IO8 stores the address range of the CRS 
62 for later use, e.g., in buffer 16C (Fig. 1) of memory 
16 (Fig. 1). Block 110 generates the FAT 58 and IVT 
64. Sub-block 112 allocates FAT entries to individual 
SSF's. Sub-block 114 stores SSF entry addresses in 
corresponding FAT entries. Sub-block 116 loads the 
reference addresses corresponding to individual CRS 
62 entries into corresponding entries in the IVT 64, 
which are accessed via corresponding interrupt num- 
bers. 

B. Detection and Execution of Cross-domain 
Calls. 

Fig. 4 depicts a run-time method 200 for execut- 
ing the program 35 after the FAT 58, CRS 62, and IVT 
64 have been set-up as just described. Block 202 
uses a conventional interpreter 12A (Fig. 1) imple- 
mented preferably by CPU 12 (Fig. 1) to execute the 
foreign program code by interpretation. 

Block 204 detects any change from sequential 
program flow (referred to herein as a "branch") and 
identifies a target address for the detected branch 
(i.e., the address of a next instruction to be executed 
following the branch). In otherwords, the method 200 
traps any attempted transfer of control to a non-se- 
quential instruction. If no branch is detected, block 
202 continues to execute the program until comple- 
tion of execution thereof. 

On detection of a branch, in block 206, a detector 
12B preferably implemented by CPU 12 (Fig. 1) de- 
termines whether the target address for that branch 



5 



9 



EP 0 671 685 A2 



10 



is within the CRS range of addresses CRS_ADf_0 
through CRS_ADf_M. The detector 12B performs a 
number of operations represented by sub-blocks. 
Sub-block 208 fetches the CRS address range 
CRS_ADf_0 through CRS_ADf_M from buffer 1 6C of 5 
memory 16. and sub-block 210 tests whether the 
branch target address Is within that range. Preferably, 
method 200 uses a single range address comparison 
in detecting cross-domain calls, rather than, e.g., a 
comparison of the branch target address with muiti- io 
pie, different address ranges. 

If the target address Is not within the CRS range, 
block 212 increments the program counterf unction of 
the CPU 12, and the next instruction is executed in 
block 202. 15 

On the other hand, if the branch target address 
is within the range CRS_ADf_0 through 
CRS_ADf_M, in block 216, an execution module 12C 
(Fig. 1) preferably implemented by CPU 12 takes con- 
trol of executing a cross-domain call. The execution 20 
module 12C causes program execution by interpreta- 
tion to stop, jackets the cross-domain call so as to 
pass parameters (e.g., register identifications, etc.) 
conforming to the conventions of the called domain, 
and generally enables direct execution of a called 25 
system services routine. 

Within block 216, the method 200 includes a 
number of sub-blocks. Sub-block 222 calculates an 
offeet into the CRS 62 equal to a difference between 
one of the boundary addresses (I.e., one of the first 30 
address CRS_ADf_0 and the last address 
CRS_ADf_M) of the CRS range and the branch target 
address within the CRS 62. 

Sub-block 224 uses the calculated of fset as an in- 
dex into the FAT 58 to access a corresponding FAT 35 
entry O - M. To illustrate, the offset can be calculated 
as the difference between the target address and the 
boundary address CRS_ADf_0. Then, the offset can 
be used as an index into the FAT 58. For example, the 
offset from the CRS 62 can be scaled as necessary, 40 
e.g., multiplied by the ratio of the entry size (in num- 
ber of bytes) in the FAT to the entry size in the CRS. 
The resulting scaled offset can be added to the first 
address FAT_ADn_0 of the FAT 58 to yield a FAT ad- 
dress of a corresponding FAT entry. 45 

Next, sub-block 226 uses the FAT entry identi- 
fied by the index as an address in the native domain 
address space 52 of an entry SSF_0 - SSF_K in the 
SSFS 56. The SSFS entry so identified is the SSF en- 
try point of a called SSF routine. so 

Block 228 fetches and executes the called SSF 
routine starting with the identified SSF entry point. 
Any results from the execution of the SSF routine can 
be returned to the application program 35 via a return 
cross-domain call with appropriate jacketing furnish- 55 
ed by the CP U 1 2 (Fig. 1 ). Whether or not a return call 
is required, the method 200 next passes control to 
block 212 for continued execution of foreign code of 



the application program 35 by interpretation. 

C. Illustrative Implementation. 

With renewed reference to Figs. 1-4, an illustra- 
tive implementation of the invention will now be de- 
scribed. A particular SSF can provide display servic- 
es, and can be stored in the SSFS 56, e.g., at entry 
SSF_1 having address SSF_ADn_1. An entry (e.g., 
entry 1) in FAT 58 Is allocated to SSF_1 , and contains 
SSF_AD|,i_1 at an address therein. The address of 
that entry is identifiable using, e.g., an offset derived 
from the relative location of a branch target address 
within the address range CRS_ADf_0 - CRS_ADf_M 
in the CRS 62. 

In this example, CRS entry 1 bearing address 
CRS_ADf_1 can correspond to the display services 
SSF. A branch included in the application program can 
call the display services SSF. To do so, the branch will 
specify a target address provided directly in a branch 
or jump instruction or indirectly via the IVT 64. The 
branch target address will be CRS_ADf_1 . The offset 
can be computed by subtracting the lowest address 
in the CRS 62, i.e., CRS_ADf_0, from the branch tar- 
get address, to yield an offset of one. 

The call for the display services SSF requires a 
domain cross for direct execution of that SSF, i.e., the 
call crosses the domain boundary 65 between the for- 
eign domain address space 54 and the native domain 
address space 52. 

The offeet can be used to identify a correspond- 
ing entry in the FAT 58, e.g., by using the offset as an 
index into the FAT 58, as described above. Where the 
scaled offset equals one, and this value is added to 
the lowest address of the FAT 58, this approach pro- 
vides the address FAT_ADn_1 of an entry in the FAT 
58 whose contents are the address, e.g., 
SSF_ADn_'I. of an entry point of the display services 
SSF. The display services SSF can then be executed. 

This implementation can be better understood 
with further reference to Fig. 5. That diagram depicts 
an implementation of a memory address space 300 
with mappings between a native address space 302 
and an emulated address space 304 analogous to 
Fig. 2. The native address space 302 has uniquely 
specified addresses assigned to all memory loca- 
tions of the native domain used for direct execution by 
computer system 10 (Fig. 1). The emulated address 
space 304 is generated by an emulator 30 and has 
uniquely specified addresses assigned to all memory 
locations accessible by the emulated computer sys- 
tem 32 (Fig. 1). 

Addressing within the native and emulated ad- 
dress spaces 302, 304 preferably conforms with the 
respective architectures of the computers 10, 32 ac- 
cessing those spaces. The native address space 302 
includes a space 312 for storing a foreign program, 
e.g., code for controlling the display 24A (Fig. 1) and 
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data related thereto, and display buffers and registers 
314. The addresses spaces 312, 314 can be as- 
signed, e.g., to portions of native address space 302 
located on a graphics card 346 (Fig. 1) connected to 
the native CPU 12 by means of an expansion bus 318. 5 

The native address space 302 also includes a 
FAT 322, SSFS 324, memory buffer 326 and an ad- 
dress space 328 for system software. Including native 
operating system. The address spaces 322-328 can 
be assigned to random access memory ("RAM") 1 6A io 
of a computer system, e.g., system 10 of Fig. 1. 

The emulated address space 304 includes a CRS 
332, an address space 334 for a target program, a dis- 
play buffers and registers space 336 for graphics 
code and data, and an address space 338 assigned 15 
to low memory, including an IVT. The address space 
334 for the target program Is assigned to a read-only 
memory 16B (Fig. 1) that contains the foreign pro- 
gram as the targetfor execution by Interpretation, i.e., 
a mapped version of the foreign program. Likewise, 20 
the space 336 contains the contents of the display 
buffers and registers 314 In a manner accessible by 
the emulator 30. 

A call can take the form of a standard interrupt for 
display services referred to as INT 10. The IVT within 2S 
address space 338 can contain a reference address 
in the CRS address space 332 corresponding to INT 
10, as illustrated by arrow "a". 

The reference address can be used to obtain an 
offset, which permits access to a corresponding entry 30 
in the FAT address space 322 as illustrated by arrow 
"b" to obtain an address therein in the native address 
space 302. 

The fetched address from the FAT address space 
322 can then be used in accessing the SSFS 324 as 35 
illustrated by arrow °c" to fetch therefrom an entry 
point, e.g., a first instruction or line of code, for the 
display services. 

The display services are then directly executed, and 
control is returned to the emulated address space 40 
304 for renewed execution of the target program by 
interpretation. 

D. Alternative Embodiments. 

45 

The above-described Figs. 1-5 depict the Inven- 
tion as practiced with regard to interrupt handling for 
branching to SSF's designated by an IVT using an off- 
sets to determine target addresses for cross-domain 
calls. 50 

The invention can be practiced more generally by 
detecting cross-domain calls resulting from branch or 
jump instructions or any other events or conditions 
causing branches for execution of routines in a cross- 
domain. ' 55 

Also, the invention need not use an offset to 
translate a branch target address in one domain into 
an target address in another domain. Instead, the 



branch target address in the CRS can be mathemat- 
ically manipulated to yield the other address. The 
mathematical manipulation of the branch target ad- 
dress can take any of a variety of different forms. For 
example, an arithmetic operation can be performed 
on the branch target address, such as the addition, 
substraction, or multiplication of the branch target ad- 
dress (which is treated as an integer for these purpos- 
es) by a constant to yield the a corresponding address 
in the native domain. Another embodiment can use a 
transformation polynomial on the target address to 
yield the other address. 

In addition to the emulation applications dis- 
cussed aboye, the invention can find particular utility 
in multi-processor computer systems in which the 
processors are of different architectures. In such an 
application of the invention, a first processor can be 
deemed the native CPU 12 of Fig. 1, and a second 
processor can be deemed the foreign processor 34, 
and the invention can be carried out as shown and de- 
scribed without regard to direct execution verses exe- 
cution by interpretation, and without regard to emula- 
tion. 

The invention has been shown and described 
hereinabove with respect to an illustrative embodi- 
ment thereof. The terms and expressions that have 
been employed are used as terms of description and 
not of limitation. It should be understood by those skil- 
led in the art that the foregoing and various other 
changes, additions and substitutions as exemplified 
by the illustrative embodiment may be made without 
departing from the scope of the invention. 

Claims 

1. A computer-implemented method for detecting 
and executing a call from a first program being 
executed in a first architectural domain for execu- 
tion of a second program in a second architectu- 
ral domain, said first architectural domain being 
characterized by a first architecture including a 
first instruction set, said second architectural do- 
main being characterized by a second, different 
architecture including a second instruction set, 
said first program being adapted for execution in 
said first architectural domain and including in- 
structions from said first set of instructions, said 
second program being adapted for execution in 
said second architectural domain and including 
instructions from said second set of instructions, 
said method comprising the steps of: 

A) detecting whether said call specifies a tar- 
get address within a predetermined address 
range in a foreign address space in said first 
architectural domain; 

B) responsive to the target address being 
within said predetermined range, determining 
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a called address in said second architectural 
domain corresponding to said target address 
in said first domain by mathematically manip- 
ulating said target address; and 
C) fetching and executing instructions of said 5 
second program specified by said called ad- 
dress in said second architectural domain, 
whereby said computer system can execute 
said first program within said first architectu- 
ral domain, and can detect and execute a io 
cross-domain call in said first program for 
execution of instructions of said second pro- 
gram within said second architectural domain. 

2. The computer-implemented method in accor- 15 
dance with claim 1, wherein said predetermined 
address range includes first and second bound- 
ary addresses defining said range, and said 
called address determining step includes the step 

of mathematically manipulating said target ad- 20 
dress by performing the steps of; 

A) determining an offset between said target 
address and one of said first and second 
boundary addresses, and 

B) using said offset within a second predeter- 25 
mined address range in said second architec- 
tural domain to identify said called address 
therein at which said second program code is 
stored. 

30 

3. The computer-implemented method in accor- 
dance with claim 1, wherein said mathematically 
manipulating step includes the step of performing 
an arithmetic operation on said target address to 
yield said called address. 35 

4. A computer-implemented method for detecting 
and executing cross-domain calls in an applica- 
tion program comprising a plurality of instructions 

of a first instruction set characteristic of a first 40 
computer architecture, each said cross-domain 
call including a branch, each said branch being a 
non-sequential change In a predetermined flow 
of execution of instructions of said application 
program, said method comprising the steps of; 45 

A) determining whether a target address spe- 
cified by a branchof eachof a plurality of calls 
included in said application programfalls with- 
in a reference address range within a first do- 
main, and thus is indicative of a cross-domain 50 
call; 

B) if said target address falls within said ref- 
erence address range, executing said cross- 
domain call specifying said target address by 
determining a called address in a second do- 55 
main corresponding to said target address in 
said first domain by mathematically manipu- 
lating said target address; and 



C) accessing said called address and execut- 
ing instructions stored therein of a s cond in- 
struction set characteristic of a second com- 
puter architecture. 

5. A method of executing an application program in- 
cluding instructions of a first instruction set char- 
acteristic of a first computer architecture com- 
prising the steps of: 

A) executing at least a portion of said applica- 
tion program by interpretation in a computer 
system having a second computer architec- 
ture, said application program having at least 
one call for executing a system services func- 
tion routine including instructions selected 
from a second instruction set characteristic of 
said second architecture; 

B) determining whether a target address of a 
next instruction to be executed falls within a 
reference address range with in a first domain, 
said target: address being specified by said 
call; 

C) if said target address falls within said ref- 
erence address range, executing said call by 
determining a called address in a second do- 
main corresponding to said target address in 
said first domain by treating said target ad- 
dress as a number and mathematically manip- 
ulating said target address; and 

D) accessing a memory location correspond- 
ing to said called address and executing said 
systems services routine commencing with 
code stored therein. 

6. A method of executing a first program on a first 
processor having a first architecture defining a 
first domain, and a second program on a second 
processor having a second architecture defining 
a second domain, said first program including a 
plurality of calls including a cross-domain call for 
execution of said second program, said method 
comprising the steps of: 

A) executing a plurality of instructions of said 
first program on said first processor, said in- 
structions being of a first instructions set 
characteristic of said first architecture; 

B) determining whether a target address spe- 
cified by each said call Included in said in- 
structions falls within a reference address 
range within said first domain; 

C) if said target address fails within said ref- 
erence address range, executing said call as 
said cross-domain call; said call executing 
step including the step of determining a called 
address in said second, domain correspond- 
ing to said target address in said first domain 
by mathematically manipulating said target 
address; and 



8 



15 



EP 0 671 685 A2 



16 



D) accessing said called address and execut- 
ing said second program commencing with 
code stored at said called address, said code 
specifying instructions of a second instruc- 
tion set characteristic of said second architec- s 
ture. 

7. The method in accordance with claim 6, wherein 
said determining step (B) comprises the steps of: 

A) establishing a cross-domain reference io 
space having a plurality of independently ad- 
dressable memory locations, each corre- 
sponding to a callable address in said second 
architectural domain and to one of said ad- 
dresses in said reference address range; 15 

B) determining' whether said target address 
specifies one of said locations. in said cross- 
domain reference table. 

8. Apparatus for detecting and executing a call from 20 
a first program being executed in a first architec- 
tural domain for execution of a second program 

in a second architectural domain, said first pro- 
gram including instructions of a first instruction 
set and said program including instructions of a 25 
second instruction set, said apparatus compris- 
ing: 

A) means operable during execution of said 
first program for detecting whether said call 
specifies a target address within a predeter- so 
mined address range in a foreign address 
space in said first architectural domain; 

B) means coupled with said detecting means 
and responsive to said target address being 
within said predetermined range for determin- 35 
ing a called address in said second architec- 
tural domain corresponding to said target ad- 
dress in said first architectural domain by 
mathematically manipulating said target ad- 
dress; and 40 

C) means for fetching and executing said sec- 
ond program instructions specified by code 
located at said called address in said second 
architectural domain. 

45 

9. The apparatus in accordance with claim 8, 
wherein said predetermined address range in- 
cludes first and second boundary addresses de- 
fining said range, and said called address deter- 
mining means includes means for mathematically so 
manipulating said target address including: 

A) means for determining an offset between 
said target address and one of said first and 
second boundary addresses, and 

B) means for using said offset within a second 55 ' 
predetermined address range in said second 
architectural domain to identify said called 
address therein at which said second program 



code is stored. 

10. The apparatus in accordance with claim 8, 
wherein said mathematically manipulating step 
includes the step of performing an arithmetic op- 
eration on said target address to yield said called 
address. 

11. Apparatus for detecting and executing a call from 
a first program including instructions of a first in- 
struction set executable in a first architectural do- 
main for execution of a second program including 
instructions of a second instruction set executa- 
ble in a second architectural domain, said appa- 
ratus comprising: 

A) a cross-domain reference space having a 
plurality of independently addressable mem- 
ory locations, each corresponding to a call- 
able address in said second domain and hav- 
ing an address in a reference address range 
in said first architectural domain; 

B) first means coupled with said cross- 
domain reference space and operable during 
execution of said first program for determining 
whether a branch target address specified by 
said first program falls within said reference 
address range and thus corresponds to a 
cross-domain call; said first means identify- 
ing one of said addresses in said reference 
address range as corresponding to said 
branch target address for each said cross- 
domain call; 

C) a second-domain address table having a 
plurality of entries each for storing one of said 
callable addresses; 

D) second means responsive to said identi- 
fied one address in said reference address 
range for designating an entry in said second- 
domain address table, and 

E) third means coupled with said second-do- 
main address table for fetching an instruction 
of said second program stored in a code- 
storage location identified by said address 
stored in said designated entry of said sec- 
ond-domain address table; 

F) means coupled with said third means for 
executing said fetched instruction. 
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